The rules were baffling when I ran in to them trying to add some impls,
so I made the compiler explain them to me.

The logic of the successful cases is unchanged, but I did rearrange it
to reverse the order of the primitive and `Adt` cases; this makes
producing the errors easier.

Use orphaned error code for the same error it belonged to before.

```
error[E0665]: `#[derive(Default)]` on enum with no `#[default]`
  --> $DIR/macros-nonfatal-errors.rs:42:10
   |
LL |   #[derive(Default)]
   |            ^^^^^^^
LL | / enum NoDeclaredDefault {
LL | |     Foo,
LL | |     Bar,
LL | | }
   | |_- this enum needs a unit variant marked with `#[default]`
   |
   = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)
help: make this unit variant default by placing `#[default]` on it
   |
LL |     #[default] Foo,
   |     ~~~~~~~~~~~~~~
help: make this unit variant default by placing `#[default]` on it
   |
LL |     #[default] Bar,
   |     ~~~~~~~~~~~~~~
```

…ecific

Use E0665 for missing `#[default]` on enum and update doc

The docs for E0665 when doing `#[derive(Default]` on an `enum` previously didn't mention `#[default]` at all, or made a distinction between unit variants, that can be annotated, and tuple or struct variants, which cannot.

E0665 was not being emitted, we now use it for the same error it belonged to before.

```
error[E0665]: `#[derive(Default)]` on enum with no `#[default]`
  --> $DIR/macros-nonfatal-errors.rs:42:10
   |
LL |   #[derive(Default)]
   |            ^^^^^^^
LL | / enum NoDeclaredDefault {
LL | |     Foo,
LL | |     Bar,
LL | | }
   | |_- this enum needs a unit variant marked with `#[default]`
   |
   = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)
help: make this unit variant default by placing `#[default]` on it
   |
LL |     #[default] Foo,
   |     ++++++++++
help: make this unit variant default by placing `#[default]` on it
   |
LL |     #[default] Bar,
   |     ++++++++++
```

Support pretty-printing `dyn*` trait objects

- Tracking issue: rust-lang#102425

Explain why a type is not eligible for `impl PointerLike`.

The rules were baffling when I ran in to them trying to add some impls (to `std`, not my own code, as it happens), so I made the compiler explain them to me.

The logic of the successful cases is unchanged, but I did rearrange it to reverse the order of the primitive and `Adt` cases; this makes producing the errors easier. I'm still not very familiar with `rustc` internals, so let me know if there's a better way to do any of this.

This also adds test coverage for which impls are accepted or rejected, which I didn't see any of already.

The PR template tells me I should consider mentioning a tracking issue, but there isn't one for `pointer_like_trait`, so I'll mention `dyn_star`: rust-lang#102425

… r=lqd

coroutine_clone: add comments

I was very surprised to learn that coroutines can be cloned. This has non-trivial semantic consequences that I do not think have been considered. Lucky enough, it's still unstable. Let's add some comments and pointers so we hopefully become aware when a MIR opt actually is in conflict with this.

Cc `@rust-lang/wg-mir-opt`

Use `&raw` for `ptr` primitive docs

Fixes the first item in rust-lang#133024

Flatten effects directory now that it doesn't really test anything specific

These are just const trait tests now, after all.

There was one naming conflict between the aux-build `tests/ui/traits/const-traits/effects/auxiliary/cross-crate.rs` and `tests/ui/traits/const-traits/auxiliary/cross-crate.rs`. The former didn't really test anything useful since we no longer have an effect param, so I removed the test that owned it: `tests/ui/traits/const-traits/effects/no-explicit-const-params-cross-crate.rs`.

r? project-const-traits